Engineering Handbook

Entwicklungs-Regeln
& Infrastruktur

Verbindliche Standards für die gemeinsame Entwicklung

0 Warnings TypeScript strict Hohe Test-Coverage Pflicht-E2E Accessibility AA EU-Stack ~80 Quality-Gates
Produkt: HiveGrid 2.0 – B2B-SaaS für CRM & projektbasiertes Arbeiten
Codebasis: Git-Downstream des HiveGrid-Boilerplates (pnpm-Monorepo)
Stand: 14. Juni 2026
Grundsatz: Regeln sind durch automatische Gates erzwungen, nicht durch guten Willen. Was rot ist, wird nicht gemerged.
HiveGrid

Inhalt

  1. Was HiveGrid Cloud ist (Produktkontext)
  2. Codebasis-Modell: Git-Downstream & Package-Namen
  3. Grundprinzipien
  4. Code-Qualität & Linting (0 Warnings)
  5. TypeScript & Typsicherheit
  6. Formatierung (Prettier)
  7. Unit- & Integrationstests + Coverage
  8. End-to-End-Tests (Playwright)
  9. Accessibility (a11y)
  10. Quality-Gates: Commit → Push → Merge → Deploy
  11. CI/CD-Pipeline
  12. Infrastruktur & Hosting
  13. Architektur-Konventionen (inkl. EU-Stack)
  14. Onboarding-Checkliste

1. Was HiveGrid Cloud ist

HiveGrid 2.0 ist ein B2B-SaaS für Kontaktmanagement (CRM) und projektbasiertes Arbeiten – mit konsequent europäischem Datenschutz- und Hosting-Anspruch.

Begriffsklärung HiveGrid Cloud ist die SaaS-Anwendung (dieses Repo, in aktiver Entwicklung). Die Marketing-Website hivegrid.de ist ein separates Projekt auf einem anderen Host – nicht zu verwechseln.

2. Codebasis-Modell: Git-Downstream & Package-Namen

HiveGrid Cloud ist kein klassischer Fork, sondern ein Git-Downstream des HiveGrid-Boilerplates: Verbesserungen aus dem Boilerplate werden per git merge upstream/main übernommen. Damit das funktioniert, bleiben Package-Namen und Konfiguration absichtlich kompatibel.

Wichtig zu den Package-Namen (häufiges Missverständnis) Es gibt kein flächiges Rename auf @hivegrid/*. Geteilte Boilerplate-Pakete behalten @hivegrid/* – sonst brechen Upstream-Merges. Entscheidung dokumentiert in docs/ARCHITECTURE-DECISIONS.md und AGENTS.md.
ScopeWofürBeispiele
@hivegrid/*Alle vom Boilerplate geteilten Pakete (bleiben so, für Mergebarkeit)@hivegrid/web, @hivegrid/api, @hivegrid/db, @hivegrid/foundation, @hivegrid/ui-app, …
@hivegrid/*Nur genuin neue HiveGrid-Pakete, die es upstream nie gibt@hivegrid/activity (Activity-Stream-Service)

Mapping-Hinweis: Wo ältere Docs/Pläne packages/ui-hivegrid oder @hivegrid/foundation sagen, ist real packages/ui-app bzw. @hivegrid/foundation gemeint. Ein späterer Naming-Drift-Fix ist in den ADRs als Option notiert, aber bewusst noch nicht umgesetzt.

Neu in HiveGrid: @hivegrid/activity – zentraler Activity-Stream/Änderungs-Historie, hängt nur an @hivegrid/db. Weitere HiveGrid-spezifische Pakete folgen demselben Muster.

Node-Version: HiveGrid nutzt v22.12.0 (.nvmrc) – neuer als der Boilerplate. Vor der Arbeit nvm use ausführen.

3. Grundprinzipien

LeitsatzFehler nach links schieben: Was lokal in Sekunden gefangen werden kann, läuft im Pre-Commit-Hook. CI ist Sicherheitsnetz, nicht erster Prüfer.

4. Code-Qualität & Linting

ESLint mit @typescript-eslint, import, jsx-a11y, react-hooks (Basis plugin:jsx-a11y/recommended). Konfiguration identisch zum Boilerplate.

Die wichtigste Regelpnpm run lint = eslint --max-warnings=0 --ext .tsx,.ts . — Null Warnings. Es gibt keine „gelben" Builds.

Harte Regeln (Error-Level)

RegelWirkung
no-debuggerKein debugger.
no-console (Server)In Server-Code (*.server.ts, apps/api, apps/worker, packages/*/src, Service-/DB-Layer) verboten; in UI/Tests/Skripten erlaubt.
no-restricted-importsKein direkter @prisma/client (nur über @hivegrid/db); keine direkten src/*-Imports zwischen Packages; foundation/view-models ohne React/UI; UI-Packages ohne DB.
no-restricted-syntax (Phase-C-UI)Keine hartkodierten nutzersichtbaren Strings in ui-app/ui-subframe/ui-mock – alles über i18n-Keys.

Accessibility-Lint & Escape-Hatch-Baseline

jsx-a11y-Regeln „monoton fallend": bei 0 Verstößen werden sie auf error hochgestuft und können nie wieder regredieren. Type-/Lint-Ausnahmen sind gedeckelt (verify:eslint-baseline): max. 262 eslint-disable, 35 @ts-ignore, 43 @ts-expect-error. Neue brauchen Baseline-Erhöhung + Review.

Datei-Limits: apps/api/src/app.ts ≤ 450 Zeilen, API-Route-Module ≤ 500 Zeilen (verify:source-health).

5. TypeScript & Typsicherheit

React-Router-v7-RegelRouten-Typen immer aus ./+types/[routeName] (nie relativ). Fehlen Typen → pnpm run typecheck, nie den Importpfad „reparieren".

6. Formatierung (Prettier)

EinstellungWertEinstellungWert
printWidth160semitrue
singleQuotefalse (Double Quotes)tabWidth2 (Spaces)
trailingCommaes5arrowParensalways
endOfLinelfPluginprettier-plugin-tailwindcss

7. Unit- & Integrationstests + Coverage

Vitest + Testing Library (jsdom), Coverage-Provider v8. Schwellen identisch zum Boilerplate und pro Verzeichnis erzwungen (verify:test-coverage gegen scripts/coverage-targets.json).

Kritischer PfadStatementsBranches
API Auth99 %92 %
Billing99 %97 %
Tenant-Isolation99 %99 %
Session / Permissions99 %98 %
Legacy-Provider95 %90 %
Basis-Targets (z. B. apps/api)70 %60 %

Test-Dichte-Gate (Pre-Commit): Mindestverhältnis Tests/Quelldateien je Workspace (z. B. apps/api ≥ 0,18; App-Routes ≥ 0,05; packages/brand/config ≥ 0,50). Neue HiveGrid-Pakete (z. B. @hivegrid/activity) brauchen eigene Tests.

Konventionen: *.test.ts(x) / *.spec.ts; Boundary *boundary.test.ts; a11y *.a11y.test.tsx / *.axe.test.tsx.

8. End-to-End-Tests (Playwright)

Verzeichnis tests/e2e (~39 Specs). Chromium, optional Mobile-Matrix (Pixel 5 + iPhone 13). Seriell, Timeout 120 s, Traces bei Fehlern. E2E laufen nächtlich gegen die Live-Staging-Umgebung; Basis ist ein deterministischer Readiness-Tenant (seed:e2e-readiness).

a11y-Coverage-Gate (pinnt Tests wörtlich)

verify:a11y-coverage verlangt ≥ 12 Component-a11y-Tests und ≥ 7 E2E-a11y-Specs und prüft wörtliche Snippets kritischer Flows (z. B. expectNoCriticalA11yViolations(, expectNoHorizontalOverflow().

Nach E2E-RefactorsDas Gate matcht literale Strings. Tests umbenennen/umbauen → verify:a11y-coverage erneut laufen lassen.

RR7 Single-Fetch-Interceptor-Contract

Form-POST-Interceptoren müssen das .data-Ziel matchen und turbo-stream zurückgeben (kein rohes JSON), inkl. X-Remix-Response: yes. Helfer in tests/e2e/utils/navigation.ts.

Pflicht-Flows (Auszug): Registration/Onboarding, Golden-Path, Subscription-Smoke, Plugin-Settings/-Lifecycle, Workflow-Builder+Run, Members, Audit, Profile-Security, Privacy, API-Keys, Mobile-Shell.

9. Accessibility

jsx-a11y-Lint · verify:color-contrast (WCAG 2.2 AA) · axe-core-Suite (test:a11y) · Mobile-Overflow-/Violation-Checks in E2E · Lighthouse-a11y als Warnung.

10. Quality-Gates: Commit → Push → Merge → Deploy

Beim Commit lefthook pre-commit · parallel

lint-staged (ESLint auf geänderten Dateien) · verify-secrets · verify-eslint-baseline · verify-test-density.

Beim Push lefthook pre-push · seriell

typecheck · verify-hardcoded-strings (i18n). Notfall-Bypass nur mit LEFTHOOK=0, nie auf main.

Beim Merge (CI) blockiert

Jobs quality + api + worker + database + docker-smoke müssen grün sein (Typecheck, Lint, Tests, Build, Bundle-Size, a11y, ~18+ Baseline-Gates).

Beim Deploy blockiert

Preflight-Gates (deploy-readiness, docker-baseline, docker-non-root). Produktions-Promote erfordert backup_confirmed=true.

11. CI/CD-Pipeline

Zwei parallele Welten mit gleichen Gates: GitHub Actions und Gitea (self-hosted Runner). Eigene Gates sichern die Parität. ci.yml-Jobs: quality, api, worker, database, docker-smoke.

Die ~80 verify:*-Gates sind Baseline-/Anti-Regressions-Gates. Gruppen: Security/Auth · Mandantentrennung/Boundaries · Docker/Deploy · i18n/a11y · API/Specs · CI-Struktur · Docs.

Lighthouse & SEOPerformance ≥ 95 % ist hart gegated; a11y/Best-Practices/PWA nur Warnung. SEO ist bewusst nicht gegated (B2B-SaaS).

12. Infrastruktur & Hosting

HiveGrid Cloud läuft im gemeinsamen Hetzner-Estate (EU/Deutschland), zentral über Coolify gesteuert. Detail-Inventar im separaten Dokument „Server-Struktur". Das Wesentliche:

EU-HostingCompute, Daten und Object-Storage (S3) liegen in der EU – auf Hetzner (Deutschland), orchestriert über Coolify. Das stützt die EU-Datenschutz-Vorgaben aus Abschnitt 13.

13. Architektur-Konventionen

14. Onboarding-Checkliste

Vor dem ersten Commit
  1. nvm use (Node v22.12.0), dann pnpm install – installiert die Hooks automatisch.
  2. AGENTS.md + docs/ARCHITECTURE-DECISIONS.md lesen (Package-Modell, EU-Stack, Milestone-Struktur).
  3. pnpm run dev starten – generiert die RR7-Routen-Typen.
  4. pnpm run typecheck & pnpm run lint sauber (0 Warnings); vor Push pnpm test grün.
  5. Für E2E: seed:e2e-readiness, .env.e2e-readiness sourcen, dann verify:a11y-coverage + Playwright.

Goldene Regel: Wenn ein Gate rot ist, ist die Lösung der Code – nicht das Umgehen des Gates.


Stand 14. Juni 2026. Quellen: HiveGrid-Cloud package.json, .eslintrc, .prettierrc, tsconfig.json, vitest.config.ts, playwright.config.ts, lefthook.yml, scripts/coverage-targets.json, AGENTS.md, docs/ARCHITECTURE-DECISIONS.md sowie das infra-Repository. Konfiguration ist – bis auf Node-Version und HiveGrid-spezifische Pakete/Docs – identisch zum HiveGrid-Boilerplate.